A telecommunications network has a variety of network elements, such as switches and routers. A telecommunications switch (switch) houses information related to a customer's service. A single switch may service many hundreds of customers and has many data tables within it. These tables contain data used by various network elements to deliver an array of services to customers. As customers change their services, or as other demands may dictate, the various switch tables may need to be updated. A switch is typically updated by receiving a data string. Absent the present invention, assembling this data string is a cumbersome, time-intensive, and expensive process because its format is constrained to a vendor-specified, unmodifiable configuration.
The prior-art method for updating switches, among other updateable network elements, includes receiving a data string at the switch and then processing that data string. A shortcoming of the prior art is that the format of this data string is not modifiable by a customer, such as a communications carrier. An exemplary communications carrier is the Sprint Communications Company L.P. of Overland Park, Kans. (Sprint). The customer is provided no flexibility in assembling the data string nor in configuring how the data string is to be interpreted by the switch.
Confining the switch-update string to a particular format impedes a customer's ability to efficiently update the switch. Some switches require that all fields of a data record must be populated for the update to be processed. One record may contain several hundred fields. Thus, to update a single attribute, a carrier may have to provide a complicated data string having hundreds of fields of which only one corresponds to a desired change. Sending a larger data string requires more time and consumes more bandwidth than sending a smaller string. It would be desirous and useful to have the option to update only desired fields, or even a single field, by communicating an update string that includes only those update commands corresponding to the parameter to be updated.
A customer, such as a carrier, may desire to format the data string and to control its implementation based upon the nature of various switch updates. The update string may take on a variety of forms or have various characteristics. For instance, one method of updating a table is to use a string having data elements interpreted by position. This format is referred to as positional format. Other formats exist, such as name/value-pair format.
Different string formats are optimal in different settings. A string can be optimized to be processed by a machine-to-machine interface (MMI) or a human-to-machine interface. It is also desirable to be able to select a delimiter. A certain field delimiter, such as a comma or a semicolon, may be preferable to another for a certain situation. No switch of the prior art permits these characteristics to be customized.
In contrast, the prior-art uses an inefficient, intermediary database that can be used to format an update string to be received by a switch. Prior-art systems associate a call processing engine with a switch element. Typically, this call processing engine is in the form of a conventional computer, having memory, storage, and processors. The call processing engine holds data in volatile memory, which is more susceptible to data loss than nonvolatile memory. Accordingly, redundant systems are in place to retrieve lost data. The data in memory is updated by an editor program when a transaction is received. A journal file entry is then made, indicating a memory update in the call processing engine. Alternatively, data may be written to a database.
In a telecommunications environment, placing a database before the call processing engine is a relatively inefficient method of implementing switch-update transactions. This inefficient process is used because most database engines have formatting procedures that can format a string to be received by a certain switch. However, processing millions of call processing transactions by first running them through an intermediary database is time consuming and resource intensive.
Merely removing the intermediary database is difficult, however, because doing so may eliminate the update-string formatting offered by the database. Again, prior-art vendors currently constrain the format of update strings to be processed by the call processing engine.
The present state of the art could be enhanced by providing an improved network-element component, a component that processes update-string formatting instructions and interprets data-update strings consistent with those instructions. The art could be further improved to allow direct updating of the call processing engine, whereby transactions are sent in real-time from a carrier application to the element's call processing engine with no intermediate passes through a database.